Cloud computing is a method for providing convenient, on-demand network access to a shared pool of configurable computing resources, which can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud and networked computing provides computation, software, data access, and storage services while not requiring the user know the physical location or the configuration of the provided systems. Cloud computing allows a user to rapidly grow or shrink their network usage without requiring changes in local systems, thereby making cloud computing convenient and simple to use by the end user. Cloud Computing management systems focus on auto-scaling at the virtual machine level.
The following Key Terms and Definitions are provided as general reference. The “Host” shall mean a single instance of a “Server” or a “Virtual Machine” that is used for a single internal application or function wrapped by the pneuron software. The virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. The VM is also described as infrastructure virtualization. The VM system provides a complete system platform which supports the execution of a complete operating system (OS). A hypervisor or virtual machine monitor is the software layer providing the virtualization. A hypervisor can run on bare hardware (Type 1 or native VM) or on top of an operating system (Type 2 or hosted VM). A Hypervisor software layer provides monitoring and diagnostic information and has proven successful for providers such as VMWare®.
Realm is a collection or group of hosts (VMs, physical servers or any combination of either) dynamically and logically organized to maximize specific application or applications processing and load distribution. The term “units of work” refers to initiated atomic level transactional and application requests from existing or third party applications. The term “realm management” refers to the host's ability to start, stop, expand or decrease in capacity, thereby incorporating them into an automated and distributed and application-demand elasticity working environment.
Typically, new hosts are added when system load is heavier or an increase in processing capacity is needed, in order to maintain high throughput and business maintenance, and are removed when system load is lighter, in order to reduce operating costs. Current cloud computing platforms provide a scaling elasticity capability at the total VM level and do not have visibility into specific applications that are processing on the VM. A VM can include one or multiple applications that are using VM-level resources. The “realm” is managed by a collection of dispatcher and worker nodes associated with a cluster—a combination of functions that can be combined and configured with specific application and VM processing rules to any level of complexity and specification.
A cluster can be defined with or without a realm and a realm only need be defined if the pneuron server is being required to start and stop nodes automatically. Each cluster that identifies a realm should specify a different realm name. The realm name is a human-readable unique identifier for the realm. A Cluster Group is self-defined collection of application nodes, either VMs or physical servers (referred as “hosts” hereunder), organized into a discrete set of application functions, tasks, and processing instructions. The cluster can be a set of pneurons defined to carry out a particular workflow, possibly including multiple instances of those pneurons to provide parallel processing for high throughput and redundancy for high availability.
Clusters are organized into multiple cluster groups, which include one or more applications. Each cluster can have configured parameters and behavior characteristics that are specific to one cluster. The flexible configuration model enables different application clusters to be tailored based upon specific application processing requirements. The clusters are dynamic and reform whenever there is a change in either the health of an existing VM or the addition of a new VM into the cluster.
A node is a machine running the pneuron server and particular pneurons. There can be one or more different types of nodes, such as, but not limited to, the following: a dispatcher node, a worker node, a master dispatcher node, a slave dispatcher node, a permanent node, and a transient node, for example. The dispatcher node is a node running a specialized dispatcher pneuron or cluster manager within a cluster for a specific application or group of applications. The worker node occurs within a cluster and is a node that is not running a dispatcher pneuron, but is instead running other application functions encapsulated into pneurons.
Units of work are sent through an application programming interface (API) to the dispatcher for workload evaluation and process execution. The dispatcher pneuron (or node) utilizes durable queues as work requests are initiated, evaluates the queue and sends units of work or messages to the worker instance queues based on how the workflow is defined for the cluster. The master dispatcher node responsibility is negotiated initially when the system is started and the existing dispatchers agree that one dispatcher will become the primary. Once the negotiation occurs, the primary or master dispatcher manages all processing with the other dispatchers shadowing in a standby mode. The master dispatcher controls the cluster, including distribution of units of work or messages to particular worker nodes. A cluster cannot distribute units of work without a master dispatcher. All incoming units or work are held in a pending queue until the cluster is formed and the master dispatcher is available. If the current master dispatcher becomes inoperative, the cluster dynamically reforms and the slave dispatchers negotiate amongst themselves to select one to act as the new master dispatcher. A cluster can be defined, and can operate, with no slave dispatchers, in which case, the cluster stops performing any work if the master dispatcher becomes inoperative. The permanent node is a node that is not automatically started and stopped by the pneuron software but remains as permanent component in the cluster. In contrast, the transient node is a node that can be automatically started and stopped by the pneuron software. The transient nodes are managed within an overall elasticity pool and are eligible for participation in multiple application clusters based on demand and elasticity requirements. The pneuron software does not, however, start and stop transient dispatcher nodes, only transient worker nodes.
Typically, a transient node is a virtual machine (VM) running on a host server. Finally, a subnet is a partial pneuron workflow which incorporates one or more pneurons all working on a single worker node. Each subnet is capable of executing its defined workflow on the specific VM or remote worker instance. All subnets within a cluster must have the identical set of identically connected and configured pneurons, except that each subnet runs on a different worker node. All subnets must end with a Complete Message pneuron. The Complete Message pneuron notifies the dispatcher or units of work completion and updates the server queue.
The realm node configuration defines the processing characteristics, properties, and role of the node within a cluster, i.e. “dispatcher” or “worker”. The pneuron software does not start and stop dispatcher nodes automatically, only worked nodes. The only exception is a loss of service by the current master dispatcher and this will result in the overall cluster being dynamically reformed. The realm manages the overall application VM group for targeted application clusters. The realm node configuration manages the processing model for each VM within the realm. The pneuron software does not start and stop permanent nodes automatically, only transient nodes.
Realm actions are configured and enable different elasticity and provisioning scenarios. The VM increase scenarios are: Create VM, Provision pneuron application, and start application on remote worker. The creation model can be configured to include just provisioning and starting a pneuron remote instance or creating a new VM, followed by provisioning. The VM removal scenarios include: Stop pneuron application, remove pneuron application, and remove VM. The removal model can be configured to include just stopping pneuron and removing the instance or completely removing the VM. In addition, the realm manager has been integrated using Java Management Extensions (JMX) and Message Beans (MBeans).
Requests for increase and decrease in VMs occurs by publishing the notifications to the Realm MBean, which is monitored by the cloud management system and will apply the recommendations. The Realm MBean is a non-intrusive approach, when direct interaction with the hypervisor is not preferred. The realm action requests is one of three values that provide manual override of the pneuron server's algorithm for starting and stopping transient worker nodes, regardless of other factors such as system load that made be influencing the algorithm. The action request field for each node if one of these three values, i.e. NULL, meaning manual override; STOP, meaning stop the node; or START, meaning start the node. As soon as a non-null action request is processed, the action request field is automatically reset to NULL.
A Cloud and Network Management System is an integrated system with the ability to provide cloud topography information, access and alignment of virtualized or cloud environment. The pneuron “Administration” application is a visual graphical user interface (GUI) and enables users to define and configure security, users, realms, realm nodes, and other global information. The realm and realm node composition, including the realm elasticity algorithms and models and the specific worker processing characteristics, are defined with the Administration application. The pneuron “Design Studio” is a visual graphical user interface (GUI) application development toolset and enables users to define and configure pneuron application clusters and workflows, including pneuron components and functions, their characteristics, and properties, and organize the business rules and workflow into discrete processing models at the application level. As part of the Design Studio configuration, users are able to associate the realm with the application cluster when configuring the dispatcher. Users are able to connect these functions to each other to build compound or hybrid products, add new functions to existing applications or businesses and allows the deployment and management of all these functions, workflows, products, applications and business models to both internal physical server environments, or the internal and external cloud. The Realm Manager highlighted below functions in both physical server and virtualized environments seamlessly and interchangeable. The deployment model can include completely internal fixed nodes, complete virtualized infrastructure, or a hybrid of internal fixed nodes and virtualized nodes. For sake of this explanation Virtual Machines will be used as the example host.
VMs are advantageous in that multiple OS environments can co-exist on the same computer, in strong isolation from each other. The VM can provide an instruction set architecture (ISA) that is somewhat different from that of the real machine, which can include application provisioning, maintenance, high availability and disaster recovery. VMs also have disadvantages, including the fact that a VM is less efficient than a real machine when it accesses the hardware indirectly. Also, when multiple VMs are concurrently running on the same physical host, each VM may exhibit a varying and unstable performance (Speed of Execution, and not results), which highly depends on the workload imposed on the system by other VMs, unless proper techniques are used for temporal isolation among VMs.
VMs operate at the overall Operating System (OS) level and do not operate or manage specific applications or clusters. VM utilization, elasticity, and optimization models are at the overall OS and are limited to the cloud management and hypervisor capabilities implemented for the specific vendor. Traditionally, the methodology has been simple load sharing and auto-scaling, wherein a first virtual machine is used and filled and then a second virtual machine is added, adding any needed additional virtual machines as each one is filled. Additionally, visibility into cluster group and application level processing has been limited. Traditional approaches that do offer some clustering and elastic computing, do so as either a hardware or operating system level.
The Pneuron solution (provided by the present invention) on the other hand provides visibility and elasticity at the application-cluster level and is hardware, technology and operating system independent. The application-level elasticity provides “fine-grained” demand management and enables flexible adjustments specific to applications or a group of applications within a cluster. This level of elasticity is not possible with traditional cloud management systems and enables more accurate and targeted demand management relative to how individual applications are performing and not at an aggregate VM level. This is important with regards to the Realm Manager disclosed herein. Finally, the ability to optimize at the cluster group and application level processing is limited. These disadvantages and limitations, as well as others, are why a unique and innovative process is needed.
Accordingly, what is needed is a model, configuration flexibility, and management that are application-centric as a process and technology for managing cloud-based computing, networked servers or a combination with respect to the virtual machines and the associated functions, applications and activities using virtualized infrastructure. The focus should be on providing a highly elastic and automated process model for orchestrating distributed host utilization and elasticity within a cloud computing paradigm and virtualized infrastructure at the specific application or cluster level and will provide a more effective and responsive approach for application processing, resource utilization and overall execution. The process will solve major limitations with respect to application-level processing visibility, monitoring, adjustments in capacity and utilization models, and enable flexible interfaces to cluster application processing groups and the associated performance of functions that such processes are aligned and managed against. The improved model and manager should feature added intelligence and logic, such that virtual machines can be loaded by various client determined parameters thereby enabling highly specific client management of load distribution based on cost, risk or other configurations.